<?php
namespace app\dao\goods;

use app\dao\BaseDao;

use app\model\Goods;

class GoodsDao extends BaseDao
{
    private $_customQuery;

    public function __construct()
    {
        $this->_customQuery = new GoodsQueryDao();
    }

    protected function setModel(): string
    {
        return Goods::class;
    }

    public function customQuery()
    {
        return $this->_customQuery;
    }

    /**
     * dao是夹在数据访问与业务之间的，所以他只面对业务和数据
     * 面对业务：提供业务逻辑涉及到的一切数据服务，例如：查数据、改数据等
     * 面对数据：专注数据如何查询、写入
     * 所以：
     * 1、不需要检查字段有效性，有效性是调用dao的方法之前做的，dao只负责如何写入，
     *    有问题就让他报错，或者可以catch异常然后抛出自己定义的异常
     * 2、像create_time、update_time之类重复的字段应该集中处理，
     *    尤其update_time，面对大量业务需求update_time会经常改变，
     *    这样每个dao方法都要重复地写相同的代码
     * 3、像price、money、tags之类的字段，不应该交给业务去处理，
     *    因为业务不该专注数据应该以什么格式写入数据库，应该由dao来转换
     *    例如money，数据库保存格式是整形（分），但传入时需要浮点型（元），
     *    这样设计对于业务是友好的，业务只需要按照单位“元”来实现逻辑，
     *    并且逻辑实现后也不需要再考虑数据会以什么形式存入（专注核心业务实现，一个方法做一件事）
     * 4、dao应该接收可编辑字段，像之前分类的level、parent_id这种系统字段，
     *    因为他不属于前端可编辑字段，所以不应该由业务传入dao（不限于前端，只是举例，只要业务可编辑的也不是系统字段，
     *    前端只是业务表现的一种形式，不要掉坑，脑子老盯着前端就容易耦合了，前端与dao没有任何关系）
     * 5、有些业务是不允许改变某些字段的，像分类编辑时不能修改parent_id、type等，
     *    dao是数据安全的最后一关，所以不要偷懒贪图方便直接把传入来的数组直接写入，这样相当于把控制权交给了业务
     */
    public function add($data)
    {
        return $this->create([
            'name' => $data['name'],
            // TODO 
        ]);
    }

    public function edit($id, $data)
    {
        return $this->update($id, [
            'name' => $data['name'],
            // TODO
        ]);
    }

    /**
     * 上架
     */
    public function onSale($id)
    {
        return $this->update($id, [
            'status' => 1,
        ]);
    }

    /**
     * 下架
     */
    public function offSale($id)
    {
        return $this->update($id, [
            'status' => 0,
        ]);
    }
}
